Internet Protocol Television (IPTV) offers opportunities for telecom service providers to attract new customers to their networks. With IPTV, telecom service providers can compete with TV offerings from cable operators, satellite-TV operators, and other terrestrial service providers. IPTV also helps providers retain existing customers and prevent churn by introducing a bundled offering of Internet, voice, and IPTV services, sometimes referred to as “triple play”.
In IPTV, web-browser technology can be used to enable IPTV Service Providers to provide services of delivering media deployed in communication networks, such as wired and wireless telephone networks. Common web browser applications, such as Mozilla's Firefox and Microsoft's Internet Explorer, enable users to view specific Internet pages and other file locations accessible by the browser. Each such file location is typically identified by a Uniform Resource Identifier (URI) or similar address. In the following, URI will be used to represent a file location address although any other type of address may be used.
In general, IPTV is a technology for receiving and displaying multimedia streams at user IPTV devices, each stream being encoded in a series of IP data packets. A user IPTV device can be a Set-Top Box (STB) or a TV having similar STB capabilities. Such a User Equipment (UE) can be configured to access IPTV services, e.g., via an IP Multimedia System (IMS) of a communication network. In this description, the term “STB” will be used to represent any user IPTV device capable of receiving multimedia streams and displaying the media as TV programs. Further, the term “TV program” is used for any media item delivered from an IPTV provider, such as movies, shows, news and documentaries.
With current solutions for IPTV, it is possible for an STB user to pause a received and viewed live broadcast of a TV program and then resume viewing the program later by receiving a recording of the program stored in the network. This procedure is sometimes called “network time-shift”.
FIG. 1 is a diagram that depicts a communication scenario where the above-described procedure of network time-shift is used. In this scenario, an STB 100 initially receives a multicast media stream of a live program, or live broadcast, from a broadcasting “multicast source” 102, as shown in an action 1:1. At some point during the program, a user of the STB pauses the program in an action 1:2, such that a still picture of the paused position in the program is typically displayed by the STB 100 for the time being.
Later on, the user decides to resume viewing the program and makes a suitable input command on the STB 100 in an action 1:3, e.g. by pressing a play button or the like. The STB 110 then obtains a unicast stream of a recorded version of the remaining part of the program from a “Media Server” 104, in an action 1:4, based on a URI or similar address of the program which has been obtained from an IPTV server, not shown, when the program was paused. The unicast stream that delivers the recording of the paused program from Media Server 104 is thus set up when the user pauses the live program.
In this procedure, it is of course desirable that the program resumes at the point or position where it was paused, to provide a seamless transition of the program at the intermission between the multicast stream from multicast source 102 and the unicast stream from Media Server 104. However, the program is typically resumed with a gap or missing part between the pause position in the live program and the restart position in the recorded program, which is perceived by the user as a “jump” from the paused program, particularly when displayed as a still picture before restart, to the restarted program.
The length of this gap or jump may vary unpredictably, e.g. from less than a second to several seconds, and is therefore unknown to the user. The effect of even only a 200 ms delay is a perceivable jump in the restarted TV program, in particular after displaying a still picture, that prevents a smooth transition from the multicast stream to the unicast stream when a user tries to resume a paused live broadcast. Even in a relatively brief jump, the user may not be able to recognize how much of the program was really missing, particularly if the jump is “abrupt” e.g. occurring over a fast-moving sequence or over a change of scenes. Therefore, a jump of, say, only half a second can be perceived by the user as an unknown gap of several seconds.